📄 java-checks/src/test/java/org/sonar/java/checks/AssertThrowsInsteadOfTryCatchFailCheckTest.java:28-34
The test passes a no-op lambda context -> { // do nothing } as the check. Since the check never reports any issues, verifyIssues() will fail because the sample file contains two // Noncompliant annotations that expect issues to be raised. The test should instantiate the actual rule check class (e.g., new AssertThrowsInsteadOfTryCatchFailCheck()) once it exists, or at minimum use verifyNoIssues() if this is a placeholder. As written, this test will not pass.

📄 java-checks/src/main/java/org/sonar/java/checks/AssertThrowsInsteadOfTryCatchFailCheck.java:43 📄 java-checks/src/main/java/org/sonar/java/checks/tests/AbstractOneExpectedExceptionRule.java:38 📄 java-checks/src/main/java/org/sonar/java/checks/tests/AbstractOneExpectedExceptionRule.java:123
The check calls UnitTestUtils.doesBlockFail(block) (line 43) and AbstractOneExpectedExceptionRule imports UnitTestUtils.doesBlockFail, but the actual method in UnitTestUtils.java is still named isTryCatchFail (line 257). The rename was never applied to the utility class, so both the new check and the existing AbstractOneExpectedExceptionRule will fail to compile.

📄 java-checks/src/main/java/org/sonar/java/checks/AssertThrowsInsteadOfTryCatchFailCheck.java:38
When fail() is the last statement in the try block (e.g. try { raise(); fail(); } catch (...) {}), it means the test expects an exception to be thrown — reaching fail() means no exception occurred, which is the failure case. The correct replacement is assertThrows(), not assertDoesNotThrow(). The current message on line 38 incorrectly suggests assertDoesNotThrow() for both cases.

assertDoesNotThrow() is only correct when fail() is in the catch block (the test expects no exception).

📄 its/autoscan/src/test/resources/autoscan/diffs/diff_S8714.json:3-4
The autoscan expectations changed from hasTruePositives: true / falseNegatives: 0 to hasTruePositives: false / falseNegatives: 33. This means the rule no longer detects any issues in the real-world autoscan corpus — a complete regression in detection capability.

The commit message "Fix ruling/autoscan?" (with a question mark) suggests uncertainty. This likely indicates a bug in the rule implementation that prevents it from matching patterns found in real projects. Consider investigating which of the 33 expected matches are no longer triggered and why, rather than adjusting the expectations file to pass CI.